A portal is not an integration

When an agency owner asks whether we “integrate” with a carrier, I have learned to answer with a question: do you want to know whether it works, or how? Because the honest answer to “how” is that there are two very different kinds of connection hiding under that one word.

The 9 and the 29

Nine of the 38 carriers we connect to offer an agency API. For those, Bevel sends a structured request and gets a structured answer. No login, no screens, a median rating time around 40 seconds. Heartland Assurance and Wabash Fidelity are both in that group, Wabash as of last month.

The other 29 have a portal: the same website your CSRs log in to. For those carriers, Bevel does what a careful person would do. It signs in with credentials you have placed in the vault, fills in the same forms in the same order, reads the same confirmation page and files the result. It is slower, usually 90 seconds to two minutes, and it is more fragile, because a portal can change without notice.

What breaks, and what happens when it does

Portals change about once a quarter per carrier. A field moves, a new required question appears, a session starts timing out at eight minutes instead of fifteen. We see it immediately, because every portal run is checked against what the confirmation page should contain.

• If a run cannot be completed exactly, it stops. Nothing is half-submitted.
• The operation for that carrier drops back to held, and your queue says why: “Cornbelt Mutual changed its vehicle form on Aug 4.”
• Elena’s team repairs the connection, typically the same day, and replays the held runs through review.

In the last eight months that has happened 61 times across all portals. The median repair took 3 hours 40 minutes. None of those incidents produced a wrong submission, because a portal that does not look the way we expect is treated as a reason to stop rather than a reason to guess.

Where the passwords live

Portal connections need a login, and that deserves a plain answer. Credentials go into a vault that encrypts each one with its own key. They are never displayed again, to you or to us, and they are used only for operations you have switched on for that carrier. Every sign-in is written to your audit log with the operation that caused it.

We ask each agency to create a dedicated portal user for Bevel where the carrier allows it. Then the carrier’s own activity report shows what Bevel did under its own name, and removing access is a single step that touches nobody else.

What to ask any vendor

If you are evaluating automation of any kind, three questions will tell you most of what you need to know.

1. For each of my carriers, is the connection an API or a portal session?
2. When a portal changes, does the software stop or does it try anyway?
3. Can I see, per run, exactly what was sent and what came back?

A vendor who answers “API” for every carrier in the Midwest is describing a different Midwest from the one I work in. Most regional mutuals do not have one yet. That is not a criticism of them. It is simply the state of things, and a product for independent agencies has to work in the state of things.

The portal is not going away. The typing can.

We publish which method each carrier uses on the features page, and we move carriers from portal to API the week an API becomes available. The changelog says when.